Hey @lgbaldoni, thanks for this contribution and for bringing to my attention that I was doing libtool versioning wrong 🙈.
And also apologies for the really late reply. I hope you are still around for the feedback.

I re-read the libtool documentation regarding updating version-info which suggests the following update rules:

• Start with version information of 0:0:0 for each libtool library.
• If the library source code has changed at all since the last update, then increment revision (c:r:a becomes c:r+1:a).
• If any interfaces have been added, removed, or changed since the last update, increment c, and set r to 0.
  • If any interfaces have been added since the last public release, then increment a.
  • If any interfaces have been removed or changed since the last public release, then set a to 0.

Using the above rules, I reviewed all the library release changes to re-calculate the correct libtool version-info.

Therefore, I believe that for release version v1.4.0, the correct libtool version-info should be 3:2:0 and not 5:0:4.
Would you agree or I a calculated/interpreted something wrong?

I dug up my notes from 4 years ago. To be honest, I could never understand the rationale behind the libtool syntax too well, but if one merely wants to produce a specific soversion, this empirical formula (which I can't say is formally correct) appears to do the trick:

awk -F "." '{print $1+$2 ":" $3 ":" $2}'

• field 3 must never be higher than field 1
• major version seems to be the difference between field 1 and field 3
• minor version is field 3
• patch version is always field 2

Hope that helps.

Thanks for replying and for going back in time and find your notes on this PR! Much appreciated!
I also have to admit it is quite hard to grasp the versioning scheme for libtool at first.

I just found out a libtool version calculator here: https://www.pakin.org/~scott/ltver.html

I reviewed again all the code changes per version and using that calculator I obtained the following version-info table:

Which matches the initial table I manually calculated before.

The formula you shared has one minor issue though, which is that version v1.0.0 (first public release) is 0:0:0 in libtool version-info. Apart from that, the formula seems appropriate but it assumes that semantic versioning has been done correctly across versions, which I sadly now realised it is not the case for this library 🙈. There were interface changes that I did not reflect correctly in the released semantic versions.

If I fix your formula to account for the first public version offset:

awk -F "." '{print $1+$2-1 ":" $3 ":" $2}

and I was to follow semantic versioning strictly, your formula and the calculator both give the following table:

My opinion is that for consistency we should use 4:0:4 as if semantic versioning was followed strictly until now, and start following it strictly from now on :)

What do you think? Would you update your PR to use 4:0:4 so I can merge it?

My opinion is that for consistency we should use 4:0:4 as if semantic versioning was followed strictly until now, and start following it strictly from now on :)

What do you think? Would you update your PR to use 4:0:4 so I can merge it?

Troble is that with version-info 4:0:4 the resulting soversion is 0.4.0.
EDIT: for any linux distribution building this as shared library it would be a downgrade, requiring a patch to avoid confusion.

Troble is that with version-info 4:0:4 the resulting soversion is 0.4.0.

Ah, I forgot to consider that indeed. Good call. I went again to manually check the generated library filenames for all the releases of the library and they can be seen in the table below.

As can be seen, I have been doing the libtool versioning quite wrong, specially for version v1.3.1 🙈.

For library compatibility, the important thing is that the library soname remains as libe131.so.1 (until a new major version is relesaed) and the version numbers increase accodingly for minor/patch.

That being said, and to reduce confusion from libtool versionsing, I think is a good idea to adopt parity between release version numbering and the created library filename as you propose in this PR 👍.

I will merge this now, thanks for the interesting discussion and keeping up with this. Appreciated!